home *** CD-ROM | disk | FTP | other *** search
- Path: chronicle.mti.sgi.com!austern
- From: James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de>
- Newsgroups: comp.std.c++
- Subject: Re: Quick questions
- Date: 26 Mar 1996 10:39:26 PST
- Organization: -
- Approved: austern@isolde.mti.sgi.com
- Message-ID: <9603261132.AA22404@lts.sel.alcatel.de>
- References: <4j5b26$1e7a@mule1.mindspring.com>
- NNTP-Posting-Host: isolde.mti.sgi.com
- X-Original-Date: Tue, 26 Mar 96 12:32:46 +0100
- In-Reply-To: abell@mindspring.com's message of 25 Mar 1996 10:07:29 PST
- X-Auth: PGPMoose V1.1 PGP comp.std.c++
- iQBVAwUBMVg6NEy4NqrwXLNJAQEYrwH/eOTxxSxe9uJaXYNs+9wSwAQzjFNQyWGS
- NOweea4hAJMZProe4UOBjYIGTxIpOrSipDtzH2PVF5REQXIOmgipEQ==
- =a7AC
- Originator: austern@isolde.mti.sgi.com
-
- In article <4j5b26$1e7a@mule1.mindspring.com> abell@mindspring.com
- (Andrew Bell) writes:
-
- |> Hopefully these will have short answers, and aren't inappropriate for
- |> the newsgroup.
-
- |> 1) Is there any way to catch an exception thrown in the constructor of
- |> a statically constructed object? Does it call unexpected() or
- |> terminate() even?
-
- Exactly. There is no way to catch the exception, so terminate will be
- called.
-
- |> 2) From a previous post on this group, it looks like the standard will
- |> allow one to define conversion operators for pre-existing, source code
- |> untouchable data types. Yes? No? What will this look like? I have the
- |> May copy of the WP, and don't see any mention of this.
-
- I'm not sure what you mean here. You have always been able to define
- conversion operators for pre-existing types to *NEW* types; such
- operators are called constructors:-). If you mean somehow change the
- meaning of e.g.: int->long, then I don't think that there is the
- slightest chance of this being supported.
-
- |> 3) I often write what I call "pure wrapper" classes to give access
- |> protection and data abstraction to pre-existing data types. A pure
- |> wrapper class is a class that adds no member variables or virtual
- |> member functions to a class/struct that has no virtual functions of
- |> its own, so their size and alignment should be the same and casting
- |> between the two should be perfectly safe. The new standard doesn't
- |> have any special support (for example, allowing it automatically) for
- |> this, does it?
-
- I'd like something like this too. I often derive for the sole purpose
- of changing the default constructor.
-
- The only place where this is really an issue, however, is in arrays.
- And since vector uses the copy constructor (rather than the default
- constructor) to initialize, IMHO, it is no longer an issue there,
- either.
-
- So while some added guarantees might be nice, they really aren't worth
- the effort it would take to define them.
-
- |> 4) With RTTI, a derived class that doesn't change any virtual member
- |> funcs or add any properties to a base class still evaluates to a
- |> different object type, correct?
-
- One would certainly hope so. I cannot think of any reason why it would
- be different.
-
- --
- James Kanze Tel.: (+33) 88 14 49 00 email: kanze@gabi-soft.fr
- GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
- Conseils, Θtudes et rΘalisations en logiciel orientΘ objet --
- -- A la recherche d'une activitΘ dans une region francophone
- ---
- [ comp.std.c++ is moderated. To submit articles: Try just posting with your
- newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu
- comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
- Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
- Comments? mailto:std-c++-request@ncar.ucar.edu
- ]
-